C++ Patterns: Executing Around Sequences

Sequential control flow forms the backbone of any procedural program. Just as common function, data, and structure in a C++ program can be factored out using functions, classes, and templates, common control flow schemas can also be named and abstracted. One such recurring schema, or programming cliché, is the embracing or bracketing of a sequence by a pair of actions, such as resource acquisition and release operations executed around the actual resource usage code. The patterns in this paper document idiomatic practices for abstracting such control flow in C++. They are connected into a language and further explored through a narrative example. Preand Post-Sequence Actions Paired actions – where a function is called before some statement sequence and a corresponding function afterwards – are commonly associated with resource acquisition and release. Preand post-sequence actions are a common feature of block-scoped resource management – e.g. allocate memory, use it, deallocate it – and this programming cliché can be found time and time again across many programs. Such repetition suggests a missing abstraction, and is both error prone (from the programming perspective) and prone in the presence of error (not exception safe). What is needed is a way to capture this control flow form, encapsulating it so that it is simple and exception safe. Exceptions, Complexity, and Abstraction Idioms are context dependent. As with multi-threading, the presence of exceptions invalidates many assumptions and practices, blowing working code out of the water and into the deep abyss of debugging. Exceptions make a handful of long-standing and well-respected C++ idioms inappropriate for modern C++ [ISO1998]. For instance, the basic rules for safe assignment have changed from the ORTHODOX CANONICAL CLASS FORM [Coplien1992] to post-standard C++ [Henney1998, Sutter2000], such that the original form is no longer considered safe. Adopting old styles with new rules tends to lead to disgraceful rather than graceful failure, and exceptions are an inevitable feature of modern C++ programs. Perhaps the greatest upset to any well-laid plan of action is something out of the ordinary: The least favorite chore for most programmers is handling exceptions! The number of ways something can go wrong seems to outnumber the ways it can go right, leading to exception code that dwarfs the core program logic. Standard C++ provides a general exception-handling model that addresses the control and information flow issues. However, as it is non-local in effect it also affects the way the conventional control flow is – or should be – expressed. In many modern programs exceptions are not something that can be ignored safely, although there are cases when they can be avoided. For instance, errors that are expected rather than exceptional should rely on more traditional schemes of communication, such as returning error codes, e.g. failure to open a file. The presence of exceptions in a program can have a significant impact. It is possible, if care is not taken, for an object to be left in an indeterminate state, thereby leaving the whole program in an unstable state. Safety – and hence stability – can be classed at one of three levels [Sutter2000]: The basic guarantee states that in the presence of exceptions, the throwing object will not leak resources. The object will be in a stable and usable, albeit not necessarily predictable, state. The strong guarantee states that the program's state will remain unchanged in the presence of exceptions, that is, commit-or-rollback semantics. The nothrow guarantee promises that exceptions are never thrown. In code, exception safety can be achieved in one of two ways: Code may be scaffolded explicitly with try, catch, and throw to ensure explicit and graceful recovery. Exception-neutral code is code that works in the presence of exceptions without requiring explicit exception-handling code. Such code can also be described as exception agnostic. A sign of weakness in a class design is that it forces its user to remember lots of particular and subtle conditions of use: "function a must be called before b, unless condition c is true, in which case d must follow e, etc.". Such interfaces suggest that the design is incomplete, the user of the class is doing work that a good design would not require: Their code is verbose and repetitive, and writing it is error prone.